A typical messaging system comprises one or more messaging services that post messages associated with one or more transactions, and one or more readers that process the transactions via processing respective messages. In some instances, a transaction can be associated with one message, wherein processing the message completes the transaction. In other instances, a transaction can comprise a plurality of messages that require processing in order to complete the transaction. In addition, the plurality of messages can be posted by one or more disparate messaging services, and one or more readers may be available to process one or more of the plurality of messages.
One obstacle associated with such messaging systems is coordinating parallel message reads from the same queue by multiple readers in order to mitigate deadlock. By way of example, a first reader can lock communication with a first messaging service in order to retrieve and process one or more messages posted by the first messaging service. To complete the associated transaction, the first reader may be required to retrieve and process one or more messages posted by a second messaging service. If the second messaging service is concurrently locked by a disparate reader, the first reader will not be able to access and process the one or more messages posted by the second messaging service. Moreover, the disparate reader may be required to retrieve and process one or more messages posted by the first messaging service. Since both readers are waiting to lock the messaging service locked by the other, a deadlock situation occurs and neither reader completes respective transactions.
Another obstacle associated with messaging systems is mitigating processing messages out-of-order. When multiple readers or multiple threads read from the same queue, messages can be processed out-of-order. By way of example, a first message comprising one or more instructions for creating a transaction header and a second message comprising one or more instructions for creating transaction line items can be stored in a queue. In many instances, the transaction header message must be processed first to instantiate the transaction. However, when messages are dequeued and processed, the transaction line item message may be dequeued first, wherein an attempt to commit the transaction line item fails because the transaction does not exist yet. Such failures can cause the transaction to roll back and the message to be requeued and processed again, which can lead to inefficient utilization of resources.
Many conventional messaging products today can ensure in-order delivery of messages; however, these products typically do not provide support for serializing in-order message processing in a manner that prevents parallel queue readers from simultaneously dequeuing and attempting to process messages associated with the same transaction. Instead, the burden of coordinating queue reads by multiple queue readers is left to the application developer. Implementing such work around routines in the application layer can be difficult, and often impossible to accomplish without reducing system performance.